1. Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for restoring service label information.
2. Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as data frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
A Virtual Private Network (VPN) may be formed by securing communications between two or more networks or network elements to form a VPN tunnel, such as by encrypting or encapsulating transmissions between the networks or network elements. Using VPN tunnels enables information to be exchanged securely between geographically dispersed sites without obtaining dedicated resources through the network.
To enable devices on one VPN site to communicate with devices on another VPN site via the VPN tunnel, it is necessary to exchange routing information between the two VPN sites. Likewise, as network elements are added and removed from the networks, or as problems are encountered and fixed in the networks, the routing tables need to be updated and advertised to the other participating sites in the VPN. Whenever a route is advertised, a service label is attached to the route, as discussed in greater detail below.
There are several commonly utilized methods of establishing VPN tunnels on a network. For example, VPNs may be established by customers through the deployment of network elements configured with VPN software. These VPNs will be referred to herein as Customer Premise Equipment-based (CPE-based) VPNs. Another way of establishing VPNs is to configure the VPN at the Provider Edge (PE) network elements to allow the service provider to provision VPN services on behalf of the customer. One common way to do this is described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2547, the content of which is hereby incorporated herein by reference. RFC 2547 describes a VPN architecture in which MultiProtocol Label Switching (MPLS)-based tunnels are used to forward packets over the network backbone. A protocol referred to as Border Gateway Protocol (BGP) is used to distribute routes over the backbone for VPNs provisioned through a particular PE network element. Routing information for these Provider-Provisioned VPNS is stored in a VPN routing and forwarding table (VRF) or a distinguishable area of the PE's common VRF. VPNs established utilizing the 2547 VPN model will be referred to herein as “VRF-based VPNs.”
VRF-based VPNs may be designed to have having many different access topologies. One popular topology is commonly referred to as a “Hub and Spoke” topology, although other topologies such as a full mesh topology may be used as well. In a hub and spoke topology, the hub controls communications on the VPN such that all spokes can talk to the hub. In a “strict” hub and spoke topology, the spokes are only allowed to talk to the hub. In a “loose” hub and spoke topology, spokes are allowed to talk to each other as well, but may only do so through the hub. This allows the hub to control communication between the spokes. In a mesh topology, the sites all are allowed to talk to each other.
FIG. 1 illustrates an example of a VPN topology formed using VRF-based VPNs. As shown in FIG. 1, the VPN service provider provides interconnectivity amongst Customer Edge (CE) network elements 10. A CE device 10 is a device which resides in a VPN site 12 and connects to a Provider Edge node 14. Essentially, a CE device allows the VPN site access to one or more remote VPN sites which belong to the same VPN. A Provider Edge (PE) node is a router which attaches to one or more CE devices and peers using Interior BGP (IBGP) with at least one other PE node. The PE node allows remote access to other VPNs which are locally supported by this PE. When handling Internet Protocol (IP) traffic, a PE node acts as a Label Edge Router which terminates Label Switched Path (LSP) tunnels used to forward traffic to other PE nodes. PE nodes may be directly connected to other PE nodes, or may be connected through other network elements such as backbone routers 16. Backbone routers are commonly designated in the industry by the letter P. The provider “P” router is a backbone router which provides interior gateway protocol connectivity between PE nodes. P routers are generally not connected to CE devices and thus have no need for knowledge of VPN routing information. It may be possible for a given router to act as a PE node for some VPNs and as a P router for other VPNs.
In a VRF-based VPN context, the PE routes form the tunnel end points for the VPN tunnels and have information associated with the configuration of the VPNs on the network. The P routers, by contrast, are configured to forward traffic and have no information about the VPNs configured through them. In an MPLS network 18, this is accomplished by MPLS label switching along label switched paths through the network. Service labels are thus unrelated to MPLS labels, as MPLS labels are used to switch the traffic on the network whereas the service labels are used by the tunnel end points to specify how the tunnel traffic should be handled at the tunnel end point.
In a VRF-based VPN architecture, each VPN configured through a network element will be associated with a particular VPN routing and forwarding table (VRF). Since routes within the VRF may have non-unique IP addresses, it is not possible to designate routes globally using their IP address alone. Accordingly, it has become common to associate one or more service labels with VPNs provisioned through a particular network element.
Service labels are 20 bit identifiers that are assigned by the network element maintaining the VRF and are advertised on the network along with the route information. When a PE on the opposite end of the tunnel wants to communicate a packet of information through the VPN tunnel, it addresses it to the IP address, attaches the service label that was provided by the network element, and sends the packet out onto the MPLS network using the next hop attribute associated with the route through the network. When the terminating PE network element receives the packet, it uses the service label to identify the VRF to which the packet belongs, and uses the IP address associated with the packet to index into the VRF associated with that VPN to determine how it should handle the packet. Alternatively, the network element may forward the packet based on the service label lookup alone.
A network element may host hundreds or thousands of VPNs at the same time. Each VPN may be associated with a single service label, or multiple service labels may be assigned to each VPN. The manner in which service labels are assigned to VPNs is commonly referred to as service label management. Service label management is an important aspect of VPN management and network element design, since the service labels are used by the dataplane to determine to which VPN (or VRF) an incoming packet belongs. An error in service label management may result in routes from one VPN inadvertently being included in the wrong VRF, which compromises the security of the VPNs.
IETF RFC 2547 describes three ways in which service labels may be used, each of which has particular advantages and disadvantages. For example, service labels may be assigned on a per-VPN basis, such that each VPN is provided with one service label. This has the advantage that there are fewer service labels to keep track of and manage, and thus is the easiest to manage from a service label management perspective. Since each service label may be associated with many routes, however, the data plane is required to do a full IP lookup for each packet received and, thus, this service label management system tends to be less scalable at the data plane. Also, for particular VPN architectures, such as a strict hub and spoke topography, performing an IP lookup and taking action on an IP address basis may present security problem, as traffic may inadvertently be leaked between spokes instead of all passing through the hub.
Another way in which service labels may be assigned is on a per route basis. Since there may be many routes, this method results in an inefficient control plane implementation. Specifically, since the number of service labels must be increased to the order of the number of routes maintained by the VRFs, a very large number of service labels must be generated and managed. Since the service label, as mentioned above, is a 20 bit number, this also limits the number of routes maintainable by the VRFs to around 1 million, which causes scalability problems in the dataplane as well.
The third way service labels may be assigned is on a per next-hop basis. Generally, a network element may be connected to anywhere between 1 and 10 or so other provider and provider edge network elements. Allocating a different service label per next hop basis enables a lower number of service labels to be generated for each VRF, while accelerating handling of packets at the control plane by allowing the dataplane to determine an indication of the next hop for the packet from the service label without requiring the dataplane to do a full IP lookup for each packet. Additionally, by eliminating the IP lookup requirement, this method is frequently preferred for particular VPN topographies, such as for strict hub and spoke VPN topologies.
Different vendors have adopted one of these service label management schemes depending on their particular view of how the service labels should be used and managed. Since each service label management scheme has its advantages and disadvantages, selecting a particular service label management scheme limits what you can do with the network element. Particularly, selection of a particular service label scheme may affect the number of service labels you are required to generate and manage, as well as the number and type of lookups that must be performed by the data plane of the network element. Both of these aspects may affect the scalability of components of the network element as well as dictate the types of services the network element is able to provide.
When a control plane of a network element fails, if the service label allocations are lost, new service labels will need to be allocated for use on the network. This causes service label chum which can disrupt traffic on the network. Additionally, since some of the new service labels to be allocated by the network element may already have been distributed by the control plane prior to the failure, these labels may already be associated with other routes and other VPNs. Accordingly, it would be desirable to maintain the service label database upon failure of the control plane to avoid assigning new service labels upon failure.